Contents
Summary
The Pico W is essentially the the same as the original Pico, with additional WiFi connectivity and the option of using a new embedded MicroPython package. This report covers rerunning bit banging and CPU benchmarks detailed in my earlier ResearchGate report “Raspberry Pi Pico, Pi 4 and Pi 400 Python and C Basic Beginners Bit Banging Benchmarks.pdf” and additional ones, including to explore WiFi performance.
Bit banging benchmarks include precompiled versions, where performance was the same as on the original Pico, and others run via various MicroPython interpreters.
For the latter, the embedded MicroPython and later releases of the original version, provided an increase of nearly four times in maximum bit switching speeds, but still much slower than from compiled programs.
CPU programs run were precompiled Whetstone, Dhrystone and MemSpeed benchmarks, where performance of the latter two was the same as before,
with Whetstone slightly different results. For some unknown reason, the precompiled program has now reverted to produce the original output.
In addition, Python Pystone benchmark was run. This was produced by the original author of the Dhrystone program, allowing approximate benefits of compilation to be calculated.
WiFi tests were carried out, including between Pico W, Raspberry Pi 4, with 2.4 and 5 Ghz WiFi, and a PC, all on the same internal network.
The first tests were via the iPerf benchmark, providing estimates of the maximum achievable bandwidth of the network, between two computers. It measures continuous data streaming performance over 10 one second periods, with a Python version available for the Pico and compiled programs for the others. Areas explored were confirming data sent was recognised by receiver and performance independent monitor, effects of 5 GHz or 2.4 GHz WiFi, CPU MHz impact, and network packet sizes used. The Pico performance was relatively very slow, but nearly 10M bits per second might be adequate for Pico W applications, dealing with this sort of activity.
The next tests were via compiled ping Windows and Linux utilities, accessing the Pico W. These can be used to confirm that a Pico W is up and running, connected to the network and provide guidance on the likely performance of dealing with small sized data transfers. At the time of testing, pinging the Pico was extremely slow, but a temporary fix was obtained to allow tests to continue. The main tests comprised 30 pings, at one per second, from a Raspberry Pi 4 to a PC and the Pico W, at 10 different data sizes between 32 and 4096 bytes. These demonstrated variance in pinging times and little difference between pings to the PC and Pico W, influenced by the low level of network utilisation. Data transfer speed, whilst pinging, was calculated, achieving the same sort of levels as iPerf.
The last detailed ping tests were carried out using a recommended Python program available from github, started by pinging from Pico W to the Raspberry Pi and PC, again at one per second and between 32 and 4096 bytes.. Performance was quite similar pinging the PC and Raspberry Pi, but up 4.5 times slower than for incoming pings or up to 40 milliseconds at 4096 bytes.
The same tests were then run with sufficient data to register on Windows and Linux network monitoring utilities that take measurements over one second periods. Firstly, pinging the Raspberry Pi to the PC with minimum possible intervals of five per second. As expected, the calculated pinging performance was much greater than that registered by the monitor, the main observation being changes in packet sizes and packets per second, the latter starting at 5, then to 10, finally recorded as 16.
Pinging from Pico has a parameter for the interval of 1 for the fastest operation. Using this setting, sending data to the PC, identified the advantage of monitoring. Initially, the results appeared to be valid, with pinging times increasing linearly with a high overhead, and packet sizes similar to the last test.
Further checks showed that the performance monitor had recorded that data being transferred was greater than that sent. Other timing considerations proved that the results were invalid, indicating that the Pico W could not handle the attempted data flow.
Most tests were repeated with lighter loading, where total pinging time at each data size appeared to occupy around 50% of pinging intervals.
Then, pinging times were up to 6 times slower than from Raspberry Pi to PC. However, at less than 7 millisecond below 512 bytes or even 36 milliseconds at 4096 bytes, this might be acceptable for infrequent short responses from a Pico W.
Finally, limited tests were carried out from Pico W to Raspberry Pi, monitoring performance using the Linux utility, where overloaded and less frequent pings produced effects similar to those accessing the PC, clearing that and Windows of possible blame for the strange behaviour.
Introduction Next or Go To Start
Introduction
I have run benchmarks on the Pico W that were covered in my 2021 ResearchGate report
Raspberry Pi Pico, Pi 4 and Pi 400 Python and C Basic Beginners Bit Banging Benchmarks.pdf.
They comprise programs written in Python, and some in C, that measure performance of bit banging and CPU activity.
This report includes some programming codes, but those for my bit banging and CPU benchmarks can be downloaded in
this zip file .
The content includes source codes and precompiled executable C programs. Some instructions are included on how to manage the programs but Raspberry Pi documentation should also be studied.
Wiring details of the setup used for these tests are provided on the last page of this document.
The Pico W is essentially the the same as the original Pico, with additional WiFi connectivity. Operation can be in the same way as before. But Python programs can also be run under a MicroPython port in new firmware.
This time, detailed results are provided comparing bit banging performance of the new and old MicroPython options, taking into account the effects of new releases. The original compiled C benchmarks were run to confirm the same performance or any differences.
A Python CPU benchmark was also run, identified in the the Raspberry Pi data sheet
Connecting to the Internet with Raspberry Pi Pico W.
The code for the first WiFi benchmark, Python iPerf, was included in the above data sheet. This is intended to provide measurements of the maximum achievable bandwidth on IP networks. To run, two computers on a network are used, each having its own version of iPerf. In this case, besides the Python version on Pico, a Windows based PC provided another, and a Raspberry Pi with Linux a third, both compiled versions. Tests between these three systems, covered 2.4 and 5 GHz WiFi, performance of interpreted Python versus compiled programs, CPU MHz effects and variable data size. Linux and Windows utilities were used to confirm network performance and to identify packet sizes
The second WiFi tests involved using the ping function, compiled versions being available using Windows and Linux, with a Python variation for use on Pico W.
Similar varieties of tests, to those on iPerf, were carried out, with the emphasis on performance of different data sizes, varying from bytes to multiple kilobytes. Some tests included the use a Linux performance monitor, besides the Windows variety, where parameters were also included to identify network error conditions.
Bit Banging Benchmarks Next or Go To Start
Bit Banging Benchmarks
Benchmarking Bit Banging involves running the same functions using Python and C code, measuring performance in cycles per second with varying output switching, intended to identify overheads involved. The count of switching operations is increased in conjunction with decreasing specified output sleep time. With fast switching and no overheads, each test should take close to 20 seconds, at switching frequencies increasing from 5 to near 500000 cycles per second. These are carried out driving 1 and 13 mainly LED outputs.
The 1 and 13 output tests are also repeated with no sleeping where, in a perfect world, cycles per second should be constant but maybe different on the first test with the low pass count. An important consideration is comparing cycles per second between 1 and 13 outputs.
A third test measures cycles per second with no sleep delays where all tests could potentially run for 20 seconds with cycles per second increasing from 5 to 500000.
Python Bit Banging Benchmarks
Before running the programs on Pico W, they were rerun on the Pico, using Thonny and a later version of micropython.uf2. Then, measured performance was slightly different, some better and some worse than earlier results. As might be expected, using the same core hardware and micropython.uf2, the Pico and Pico W performance results were virtually the same.
The tests were then run using the MicroPython port in firmware.uf2, where the overheads were considerably less, resulting in faster cycles per second switching rates.
Later, the tests were rerun using newer micropython.uf2 releases that produced significant improvements, eventually reaching similar performance to the firmware runs.
Then, the programs were run again controlled by the the early uf2 versions (see 1R and 2R below), where significant performance gains were recorded. I have been unable to identify any possible reason for this improvement. The uf2 files used were:
micropython.uf2 versions
1 -- micropython-02-12-2020.uf2
2 -- pico_micropython_20210121.uf2
3 -- rp2-pico-20220117-v1.18.uf2
4 -- rp2-pico-20220618-v1.19.1.uf2
Full details of an early test session are shown below, along with cycles per second for the longest running later runs, in order to identify maximum comparative performance measurements.
Benchmarks With Sleeps
The result was that the new firmware produced maximum throughput gains of 1.55 times, driving 1 output and 3.36 with 13 (at first 10000000), but with similar performance with later Thonny based tests.
New Firmware
Pico W via Thonny and pico_micropython Pico W via New firmware Python
Pico Python one output + sleep Pico Python one output + sleep
Loops microsecs runsecs cycles/sec Loops microsecs runsecs cycles/sec
100 100000 20.01 5.0 100 100000 20.01 5.0
1000 10000 20.09 49.8 1000 10000 20.06 49.8
10000 1000 20.87 479.1 10000 1000 20.64 484.5
100000 100 28.73 3480.4 100000 100 26.39 3789.2
1000000 10 107.37 9314.0 1000000 10 77.97 12824.8
10000000 2 1 877.13 11400.8 10000000 1 563.77 17737.8
10000000 1 1 10781.0
10000000 2R 1 14788.8
10000000 3 1 18921.4
10000000 4 1 16785.2
10000000 1R 1 13432.4
Pico Python 13 outputs + sleep Pico Python 13 outputs + sleep
Loops microsecs runsecs cycles/sec Loops microsecs runsecs cycles/sec
100 100000 20.07 5.0 100 100000 20.02 5.0
1000 10000 20.73 48.2 1000 10000 20.23 49.4
10000 1000 27.30 366.4 10000 1000 22.25 449.5
100000 100 92.94 1075.9 100000 100 42.49 2353.2
1000000 10 749.35 1334.5 1000000 10 239.25 4179.7
10000000 2 1 7296.03 1370.6 10000000 1 2174.67 4598.4
10000000 1 1 1379.4
10000000 2R 1 3395.2
10000000 3 1 3777.3
10000000 4 1 4546.4
10000000 1R 1 3399.3
Continued Next or Go To Start
Python Bit Banging Benchmarks Continued
No Sleep Time
These tests provide guidance on maximum bit banging speeds. Following timer resolution issues with the low loop count tests, throughput is shown to be constant. This time, the new firmware initially gave a 2.0 times improvement in performance, with 1 output and 3.72 with 13. For the latter bits banged per second would be 72,831, only 33% faster than with 1 output.
Note improvements using later versions of the original MicroPython.
New Firmware
Pico Python one output no sleep Pico Python one output no sleep
Loops runsecs cycles/sec Loops runsecs cycles/sec
100 0.01 20000.0 100 0.00 50000.0
1000 0.04 27027.0 1000 0.02 52631.6
10000 0.37 27100.3 10000 0.18 54644.8
100000 3.69 27070.9 100000 1.83 54644.8
1000000 36.91 27093.7 1000000 18.30 54656.8
10000000 2 369.44 27068.3 10000000 182.96 54656.8
10000000 1 32214.0
10000000 2R 41514.1
10000000 3 44300.9
10000000 4 55928.4
10000000 1R 45604.4
Pico Python 13 outputs no sleep Pico Python 13 outputs no sleep
Loops runsecs cycles/sec Loops runsecs cycles/sec
100 0.06 1754.4 100 0.02 5555.6
1000 0.67 1501.5 1000 0.18 5586.6
10000 6.65 1503.8 10000 1.78 5602.2
100000 66.50 1503.8 100000 17.85 5602.6
1000000 665.00 1503.8 1000000 178.50 5602.4
10000000 2 6649.98 1503.8 10000000 1784.96 5602.4
10000000 1 1601.0
10000000 2R 3888.9
10000000 3 4291.7
10000000 4 5814.0
10000000 1R 4450.6
Sleep Time Only
With an accurate timer, all these tests should run for 20 seconds. This is where the specified microseconds can be modified attempting to produce the desired delays. This time, the new firmware microPython 1 microsecond test indicated a 30% improvement but with running time 21.5 times longer than might be expected.
New Firmware
Pico Python Sleep only Pico Python Sleep only
Loops microsecs runsecs cycles/sec Loops microsecs runsecs cycles/sec
100 100000 20.01 5.0 100 100000 20.00 5.0
1000 10000 20.06 49.9 1000 10000 20.05 49.9
10000 1000 20.56 486.5 10000 1000 20.50 487.8
100000 100 25.56 3912.8 100000 100 25.02 3996.2
1000000 10 75.33 13275.5 1000000 10 65.66 15230.2
10000000 2 1 561.32 17815.2 10000000 1 430.30 23239.4
10000000 1 1 14770.8
10000000 2R 1 21546.1
10000000 3 1 29382.6
10000000 4 1 24323.2
10000000 1R 1 17102.7
C Compiled Versions Next or Go To Start
C Compiled Bit Banging Benchmarks
Following are the latest results. Note Output with Sleep and Just Sleep tests were all completed in 20 seconds. With the No Sleep versions, 1 output tests were 10.5 times faster than with 13, but the latter relates to a mere 24% increase in total bits banged per second.
C version cycles per second performance was essentially the same as that measured on the original Pico. Then, this was reported as being more than 1000 times greater than that obtained using Python. Later versions of Python have reduced this advantage to around 350 times.
One Output + Sleep 13 Outputs + Sleep
Loops microsecs runsecs cycles/sec Loops microsecs runsecs cycles/sec
100 100000 20.000 5.0 100 100000 20.000 5.0
1000 10000 20.000 50.0 1000 10000 20.000 50.0
10000 1000 20.000 500.0 10000 1000 20.000 500.0
100000 100 20.000 5000.0 100000 100 20.000 5000.0
1000000 10 20.000 50000.0 1000000 10 20.000 50000.0
10000000 1 20.000 500000.0 10000000 1 20.000 500000.0
End End
One Output No Sleep 13 Outputs No Sleep
Loops microsecs runsecs cycles/sec Loops microsecs runsecs cycles/sec
100 0 0.000 11111111.0 100 0 0.000 1449275.4
1000 0 0.000 20408164.0 1000 0 0.001 1980198.0
10000 0 0.000 20833334.0 10000 0 0.005 1983733.4
100000 0 0.005 20828994.0 100000 0 0.050 1984127.0
1000000 0 0.048 20833334.0 1000000 0 0.504 1984127.0
10000000 0 0.480 20833334.0 10000000 0 5.040 1984127.0
End End
Just sleep
Loops microsecs runsecs cycles/sec
100 100000 20.000 5.0
1000 10000 20.000 50.0
10000 1000 20.000 500.0
100000 100 20.000 5000.0
1000000 10 20.000 50000.0
10000000 1 20.000 500000.0
End
CPU Benchmarks Next or Go To Start
CPU Performance
This is measured using three benchmarks comprising Whetstone, mainly floating point, Dhrystone, all integer and one that measures memory data transfer speeds with varying data volumes.
Pico W and Pico Whetstone double precision benchmark reported results were identical as were Dhrystones but changes to performance and demonstrated numeric accuracy were apparent for Whetstone single precision tests. Pico W numeric result formats were then the same as obtained using the version run on the Pi 4 (see below).
For some unknown reason, the precompiled program has now reverted to producing the original output.
MemSpeed measured performance was mainly identical between the two Picos, an exception being the first single precision tests, where the Pico W appeared to be slightly faster.
These CPU benchmarks are available for downloading in
PicoCode.zip .
that contains C source codes and .uf2 Pico execution programs, along with CMakeLists.txt file, needed for compilation.
Single Precision Whetstone Benchmark
Pico W Single Precision C/C++ Whetstone Benchmark
Loop content Result MFLOPS MOPS Seconds
N1 floating point -1.12475013732910156 1.546 0.099
N2 floating point -1.12274742126464844 1.549 0.694
N3 if then else 1.00000000000000000 93.665 0.009
N4 fixed point 12.00000000000000000 5.716 0.441
N5 sin,cos etc. 0.49911010265350342 0.159 4.174
N6 floating point 0.99999982118606567 1.652 2.612
N7 assignments 3.00000000000000000 53.567 0.028
N8 exp,sqrt etc. 0.75110864639282227 0.228 1.306
MWIPS 8.545 9.362
Pico Single Precision C/C++ Whetstone Benchmark
Loop content Result MFLOPS MOPS Seconds
N1 floating point -1.12475013700000000 1.493 0.103
N2 floating point -1.12274742100000000 1.495 0.719
N3 if then else 1.00000000000000000 93.729 0.009
N4 fixed point 12.00000000000000000 5.716 0.441
N5 sin,cos etc. 0.49911010300000000 0.160 4.171
N6 floating point 0.99999982100000000 1.531 2.819
N7 assignments 3.00000000000000000 53.567 0.028
N8 exp,sqrt etc. 0.75110864600000000 0.228 1.306
MWIPS 8.338 9.595
Double Precision Whetstone Benchmark
Pico W Double Precision C/C++ Whetstone Benchmark
Loop content Result MFLOPS MOPS Seconds
N1 floating point -1.12398255667391900 0.918 0.125
N2 floating point -1.12187079889284425 0.919 0.878
N3 if then else 1.00000000000000000 93.651 0.007
N4 fixed point 12.00000000000000000 4.507 0.419
N5 sin,cos etc. 0.49902937281518023 0.160 3.116
N6 floating point 0.99999987890802811 0.863 3.749
N7 assignments 3.00000000000000000 37.494 0.030
N8 exp,sqrt etc. 0.75100163018458665 0.235 0.950
MWIPS 6.470 9.273
Pico Double Precision C/C++ Whetstone Benchmark
Loop content Result MFLOPS MOPS Seconds
N1 floating point -1.12398255667391900 0.918 0.125
N2 floating point -1.12187079889284425 0.919 0.878
N3 if then else 1.00000000000000000 93.665 0.007
N4 fixed point 12.00000000000000000 4.507 0.419
N5 sin,cos etc. 0.49902937281518023 0.160 3.118
N6 floating point 0.99999987890802811 0.863 3.749
N7 assignments 3.00000000000000000 37.496 0.030
N8 exp,sqrt etc. 0.75100163018458665 0.235 0.950
MWIPS 6.469 9.275
Continued Next or Go To Start
Dhrystone Benchmark
Dhrystone Benchmark, Version 2.1 (Language: C or C++)
Pico W
Nanoseconds one Dhrystone run: 4000.00
Dhrystones per Second: 250000
VAX MIPS rating = 142.29
Pico
Nanoseconds one Dhrystone run: 4000.00
Dhrystones per Second: 250000
VAX MIPS rating = 142.29
MemSpeed Benchmark
Pico W Memory Reading Speed Test Pico
Memory x[m]=x[m]+s*y[m] Int x[m]=x[m]+y[m] x[m]=y[m]
KBytes Dble Sngl Int32 Dble Sngl Int32 Dble Sngl Int32
Used MB/S MB/S MB/S MB/S MB/S MB/S MB/S MB/S MB/S
8 6.9 6.6 97.47 18.1 11.7 88.8 107.9 95.1 95.1
16 6.9 6.6 97.52 18.1 11.7 88.9 108.0 95.2 95.2
32 6.9 6.6 97.54 18.1 11.7 88.9 108.1 95.2 95.2
64 6.9 6.5 97.55 18.1 11.7 88.9 108.1 95.2 95.2
128 6.9 6.6 97.56 18.1 11.7 88.9 108.1 95.2 95.2
Pico Memory Reading Speed Test Pico
Memory x[m]=x[m]+s*y[m] Int x[m]=x[m]+y[m] x[m]=y[m]
KBytes Dble Sngl Int32 Dble Sngl Int32 Dble Sngl Int32
Used MB/S MB/S MB/S MB/S MB/S MB/S MB/S MB/S MB/S
8 6.9 6.1 97.47 18.1 11.7 88.8 107.9 95.1 95.1
16 6.9 6.1 97.52 18.1 11.7 88.9 108.0 95.2 95.2
32 6.9 6.1 97.54 18.1 11.7 88.9 108.1 95.2 95.2
64 6.9 6.1 97.55 18.1 11.7 88.9 108.1 95.2 95.2
128 6.9 6.1 97.56 18.1 11.7 88.9 108.1 95.2 95.2
Pystone Benchmark Pico W
Pystone is a Python version of the Dhrystone benchmark, with performance measured as pystones/second. Both come from the same author Reinhold P. Weicker. The version used for Pico W can be installed (via Internet) and executed as shown in “Connecting to the Internet with Raspberry Pi Pico W.”. The result indicated there is 1243 pystones/second.
Performance appeared to increase with each new version of MicroPython and was not affected much by the short running times. A summary of pystones/second for various micropython.uf2 releases and details of my latest tests are below.
micropython.uf2 2020-02-12 690 pystones/second
micropython.uf2 2021-01-21 1086 pystones/second
micropython.uf2 2022-01-17 1298 pystones/second
firmware-240622.uf2 1412 pystones/second
rp2-pico-20220117-v1.18.uf2
MicroPython v1.18 on 2022-01-17; Raspberry Pi Pico with RP2040
Type "help()" for more information.
>>> %Run -c $EDITOR_CONTENT
Pystone(1.2) time for 500 passes = 385ms
This machine benchmarks at 1298 pystones/second
>>>
firmware-240622.uf2 Via Thonny Editor
MicroPython v1.18-673-gdf8d97171 on 2022-06-24; Raspberry Pi Pico W with RP2040
Type "help()" for more information.
>>> %Run -c $EDITOR_CONTENT
Pystone(1.2) time for 500 passes = 354ms
This machine benchmarks at 1412 pystones/second
Comparing these results with Dhrystones per Second might indicate that the C code improved potential performance by at least 175 times..
WiFi and iPerf Network Bandwidth Benchmark Next or Go To Start
WiFi Performance
In the same vein as the above programs, that were described as Basic Beginners Benchmarks, only simple tests were carried out to demonstrate Pico W communications with the outside world and provide measurement of performance that can be compared with that from other systems. Of course, these were carried out under MicroPython port in firmware.uf2 versions.
iPerf Benchmark
iPerf is a tool for network performance measurement and tuning. It is a cross-platform tool that can produce standardised performance measurements for any network, providing active measurements of the maximum achievable bandwidth on IP networks. iPerf has client and server functionality, a minor problem being that command format varies across different platforms.
In the same way as Pystone, a Python version of iPerf can be installed via Internet and executed, as shown in “Connecting to the Internet with Raspberry Pi Pico W.pdf”. There, the example provided in is for a Pico W client transferring data to a remote server, when performance is measured over one second periods indicating size up to 103 KBytes at 845 Kbits/second (8.2 bits per byte).
iPerf Pico W Client PC Server
I initially ran iPerf, on the Pico W, in June 2022, communicating with a PC server, where the performance was shown to be around 3.5 Mbits/sec or transferring near 430 KBytes of data each second.
Running using later firmware, from the detail provided below, near 10 Mbits/sec at data size greater than 1 MByte was indicated, where the PC server confirmed the results.
Pico W Client PC Server PC iPerf Recording
D:\iperf>iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.1.117, port 63055
[ 5] local 192.168.1.68 port 5201 connected to 192.168.1.117 port 63056
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.01 sec 864 KBytes 6.98 Mbits/sec
[ 5] 1.01-2.01 sec 1.14 MBytes 9.61 Mbits/sec
[ 5] 2.01-3.01 sec 1.13 MBytes 9.48 Mbits/sec
[ 5] 3.01-4.01 sec 1.08 MBytes 9.08 Mbits/sec
[ 5] 4.01-5.01 sec 1.10 MBytes 9.25 Mbits/sec
[ 5] 5.01-6.01 sec 1.10 MBytes 9.22 Mbits/sec
[ 5] 6.01-7.00 sec 1.00 MBytes 8.42 Mbits/sec
[ 5] 7.00-8.00 sec 1.15 MBytes 9.68 Mbits/sec
[ 5] 8.00-9.00 sec 926 KBytes 7.60 Mbits/sec
[ 5] 9.00-10.02 sec 1.18 MBytes 9.75 Mbits/sec
[ 5] 10.02-10.75 sec 286 KBytes 3.19 Mbits/sec
Overall
[ 5] 0.00-10.75 sec 10.9 MBytes 8.52 Mbits/sec receiver
Pico W Client PC Server Pico W iPerf Recording
>>> uiperf3.client('192.168.1.68')
CLIENT MODE: TCP sending
Connecting to ('192.168.1.68', 5201)
Interval Transfer Bitrate
0.00-1.00 sec 1.14 MBytes 9.57 Mbits/sec
1.00-2.00 sec 1.13 MBytes 9.47 Mbits/sec
2.00-3.00 sec 1.12 MBytes 9.39 Mbits/sec
3.00-4.00 sec 1.09 MBytes 9.13 Mbits/sec
4.00-5.01 sec 1.12 MBytes 9.36 Mbits/sec
5.01-6.01 sec 1.09 MBytes 9.16 Mbits/sec
6.01-7.01 sec 1.01 MBytes 8.49 Mbits/sec
7.01-8.01 sec 1.15 MBytes 9.65 Mbits/sec
8.01-9.01 sec 946 KBytes 7.74 Mbits/sec
9.01-10.00 sec 1.13 MBytes 9.58 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0.00-10.00 sec 10.9 MBytes 9.15 Mbits/sec sender
Additionally, PC Perfmon network monitoring was run, subject to not exact synchronisation of timing, but effectively confirming the same performance.
iPerf Pico To PC Performance Monitor Next or Go To Start
Pico W Client PC Server PC Perfmon Recording
Perfmon measures received and sent network data transfer speed in bytes per second and packets per second, enabling packet sizes to be calculated. In this case, Pico W packet size used was much less than that measured using a Raspberry Pi 4B. More significant, measured data transfer speed was less than 25% of that obtained on a Pi 4B, using 2.4 GHz WiFi. Then I understand that Raspberry Pi (and PC) iPerf programs are compiled, where that looks good compared with other Python interpreted/Compiled program running time comparisons.
Bytes/second Packets/second Bytes/packet %CPU
Time Received Sent Received Sent Received Sent Time
07/28/2022 15:12:35. 423264 13567 504 249 840 54 5
07/28/2022 15:12:36. 1111016 34344 1303 636 853 54 5
07/28/2022 15:12:37. 1280528 39590 1500 733 853 54 5
07/28/2022 15:12:38. 1098544 33965 1288 629 853 54 4
07/28/2022 15:12:39. 1277835 39697 1496 735 854 54 4
07/28/2022 15:12:40. 1321488 40888 1546 757 855 54 5
07/28/2022 15:12:41. 1314662 40996 1540 759 853 54 5
07/28/2022 15:12:42. 1278709 39481 1497 731 854 54 6
07/28/2022 15:12:43. 1312088 40834 1536 756 854 54 3
07/28/2022 15:12:44. 1296180 40638 1519 751 854 54 5
07/28/2022 15:12:45. 848574 26285 995 487 853 54 3
Later, following the Pi 4 results, are details of the extensive range of data transmission speeds that can be selected, in order to see if they affected packet sizes, which they didn’t.
Pi 4B CPU times used were also recorded during the Pi to PC tests, including running in the 600 MHz powersave mode (see later below). These were really low, like 0.17 seconds out of 10.5 seconds testing time, at 600 MHz. That could be approaching five times longer at Pico CPU MHz speed. Then pile in the huge Python overheads, apparent on other benchmarks, when data transfer becomes limited by CPU time and the slow Pico performance could be justified.
Note Pico transmitted packet size was around 854 bytes.
iPerf Raspberry Pi 4B to PC 5 GHz Next or Go To Start
iPerf Raspberry Pi 4B Client 5 GHz Wifi PC Server
For this and later results, only one of the iPerf reports is provided, as both indicated the same information.
This test mainly runs at full speed throughout but sometimes more slowly, as in this example. Here, the change in Congestion Window Cwnd size suggests that other activity was affecting speed. Another variation was the apparent different speeds suggested for bits and bytes. However, the former often represents bits transmitted that is greater than 8 bits per byte.
Using 5 GHz WiFi, maximum data transmission speed was shown as around 10 MBytes per second, slightly higher being indicated by PC Perfmon. My LanSpeed benchmark was also run via WiFi, measuring transmission speeds between the Raspberry Pi and PC, showing performance in the same ballpark.
Tpi@raspberrypi:~ $ iperf3 -c 192.168.1.68
Connecting to host 192.168.1.68, port 5201
[ 5] local 192.168.1.71 port 55644 connected to 192.168.1.68 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 10.0 MBytes 84.1 Mbits/sec 0 211 KBytes
[ 5] 1.00-2.00 sec 9.94 MBytes 83.4 Mbits/sec 0 211 KBytes
To
[ 5] 8.00-9.00 sec 3.60 MBytes 30.2 Mbits/sec 0 328 KBytes
[ 5] 9.00-10.00 sec 2.61 MBytes 21.9 Mbits/sec 0 328 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 0.00-10.00 sec 78.8 MBytes 66.1 Mbits/sec 0 sender
LanSpeed Benchmark Pi 4B 5 GHz
MBytes/Second
MB Write1 Write2 Write3 Read1 Read2 Read3
8 11.90 12.96 13.16 10.11 9.55 9.66
16 11.50 13.93 14.13 9.91 8.88 9.92
PC Perfmon Recording
Note Pi 4B transmitted packet size of around 1507 bytes, much greater than that used by Pico data transfer. However, other tests suggest that this would have little effect on data transmission speed.
Bytes/second Packets/second Bytes/Packet %CPU
Time Received Sent Received Sent Received Sent Time
07/29/2022 15:17:51 10774485 121430 7150 1840 1507 66 7
07/29/2022 15:17:52 10701315 119378 7100 1809 1507 66 9
07/29/2022 15:17:53 10877685 122290 7219 1853 1507 66 12
07/29/2022 15:17:54 10753381 121632 7134 1843 1507 66 5
07/29/2022 15:17:55 10938026 124006 7258 1879 1507 66 8
07/29/2022 15:17:56 10765516 122946 7145 1863 1507 66 3
07/29/2022 15:17:57 9746272 109638 6469 1661 1507 66 12
07/29/2022 15:17:58 3884336 39728 2579 602 1506 66 1
07/29/2022 15:17:59 2940738 30737 1951 466 1507 66 2
07/29/2022 15:18:00 2912284 28744 1936 436 1504 66 0
iPerf Raspberry Pi 4B to PC 2.4 GHz Next or Go To Start
iPerf Raspberry Pi 4B Client 2.4 GHz Wifi PC Server
With WiFi at 2.4 GHz, all round performance was just over half that at 5 GHz, using the same packet sizes and confirmed, with the usual assumptions, by benchmark results. Details of an iPerf report with the Raspberry Pi running at 600 MHz, instead of 1500, are also shown to produce similar transmission speed.
Pi4B IPerf Recording
pi@raspberrypi:~ $ iperf3 -c 192.168.1.68
Connecting to host 192.168.1.68, port 5201
[ 5] local 192.168.1.71 port 58510 connected to 192.168.1.68 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 4.72 MBytes 39.6 Mbits/sec 0 211 KBytes
[ 5] 1.00-2.00 sec 4.60 MBytes 38.6 Mbits/sec 0 211 KBytes
[ 5] 2.00-3.00 sec 5.28 MBytes 44.3 Mbits/sec 0 211 KBytes
[ 5] 3.00-4.00 sec 4.97 MBytes 41.7 Mbits/sec 0 211 KBytes
[ 5] 4.00-5.00 sec 4.78 MBytes 40.1 Mbits/sec 0 211 KBytes
[ 5] 5.00-6.00 sec 4.47 MBytes 37.5 Mbits/sec 0 211 KBytes
[ 5] 6.00-7.00 sec 4.97 MBytes 41.7 Mbits/sec 0 211 KBytes
[ 5] 7.00-8.00 sec 4.97 MBytes 41.7 Mbits/sec 0 211 KBytes
[ 5] 8.00-9.00 sec 4.54 MBytes 38.1 Mbits/sec 0 211 KBytes
[ 5] 9.00-10.00 sec 4.97 MBytes 41.7 Mbits/sec 0 211 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 0.00-10.00 sec 48.3 MBytes 40.5 Mbits/sec 0 sender
Pi 4 600 MHz
[ 5] 0.00-10.00 sec 45.0 MBytes 37.8 Mbits/sec 0 sender
LanSpeed Benchmark Pi 4B 2.4 GHz
MBytes/Second
MB Write1 Write2 Write3 Read1 Read2 Read3
8 6.35 6.33 6.38 7.05 6.98 7.10
16 6.70 6.82 6.76 7.19 6.53 7.22
PC Perfmon Recording
Again note Pico transmitted packet size of around 1507 bytes,also Pi 600 MHz details.
Bytes/second Packets/second Bytes/Packet %CPU
Time Received Sent Received Sent Received Sent Time
07/30/2022 10:04:18. 2049448 43758 1365 663 1502 66 4
07/30/2022 10:04:19. 4524025 95651 2999 1449 1509 66 6
07/30/2022 10:04:20. 5432915 114974 3606 1742 1507 66 6
07/30/2022 10:04:21. 5514549 115614 3659 1752 1507 66 11
07/30/2022 10:04:22. 5217710 112324 3465 1672 1506 67 10
07/30/2022 10:04:23. 5730137 126265 3803 1845 1507 68 5
07/30/2022 10:04:24. 4982276 106876 3305 1605 1507 67 5
07/30/2022 10:04:25. 5192824 116267 3441 1674 1509 69 7
07/30/2022 10:04:26. 5209633 114099 3455 1661 1508 69 7
07/30/2022 10:04:27. 5299510 112232 3517 1686 1507 67 5
Pi 4 600 MHz
07/30/2022 10:26:13 4980701 98691 3304 1495 1507 66 6
Pi 4B CPU Utilisation
pi@raspberrypi:~ $ time iperf3 -c 192.168.1.68
real 0m10.643s
user 0m0.010s
sys 0m0.080s
up to 4% CPU utilisation
iPerf Raspberry Pi 4B at 600 MHz Client 2.4 GHz Wifi PC Server
Note same performance as at full speed of 1500 MHz, but higher CPU utilisation.
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
Current Frequency:2.412 GHz (Channel 1)
pi@raspberrypi:~ $ time iperf3 -c 192.168.1.68
pi@raspberrypi:~ $ time iperf3 -c 192.168.1.68
Connecting to host 192.168.1.68, port 5201
[ 5] local 192.168.1.71 port 44948 connected to 192.168.1.68 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 5.29 MBytes 44.4 Mbits/sec 0 216 KBytes
[ 5] 1.00-2.00 sec 4.54 MBytes 38.1 Mbits/sec 0 216 KBytes
[ 5] 2.00-3.00 sec 4.35 MBytes 36.5 Mbits/sec 0 216 KBytes
[ 5] 3.00-4.00 sec 3.91 MBytes 32.8 Mbits/sec 0 216 KBytes
[ 5] 4.00-5.00 sec 4.60 MBytes 38.6 Mbits/sec 0 216 KBytes
[ 5] 5.00-6.00 sec 4.54 MBytes 38.1 Mbits/sec 0 216 KBytes
[ 5] 6.00-7.00 sec 4.35 MBytes 36.5 Mbits/sec 0 216 KBytes
[ 5] 7.00-8.00 sec 4.78 MBytes 40.1 Mbits/sec 0 216 KBytes
[ 5] 8.00-9.00 sec 5.16 MBytes 43.3 Mbits/sec 0 216 KBytes
[ 5] 9.00-10.00 sec 5.34 MBytes 44.8 Mbits/sec 0 216 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 46.9 MBytes 39.3 Mbits/sec 0 sender
Pi 4B CPU Utilisation
pi@raspberrypi:~ $ time iperf3 -c 192.168.1.68
real 0m10.573s
user 0m0.019s
sys 0m0.150s
Pi 4B iPerf Bandwidth Setting Next or Go To Start
Using Pi 4B iPerf Bandwidth Setting
Accessing Help, for Raspberry Pi and Windows iPerf versions, identifies parameters that might control the speed but could find no reference for Pico W run time options. Some success was found running a Raspberry Pi version, results being provided below, specifying the target data transmission speed.
Tests were run with target speeds of 1M to 128M bits per second with WiFi running at both 5 GHz and 2.4 GHz, and PC Perfmon recording for the latter. The aim was to see if they provided reasons for the slow Pico W performance. Subject to normal variations, All they did is to demonstrate no real difference using bandwidth throughput settings up to 32M bits per second, greater than this apparently being beyond the capabilities of 2.4 GHz.
In all cases, Perfmon effectively indicated the same packet size of just over 1500 bytes.
Performance achieved by the higher bitrate requests is of the same order as the default with no run time parameters and reducing CPU MHz from 1500 MHz to 600 made little difference. These results provide no clues as to how the Pi 4B at 600 MHz and 2.4 GHz WiFi could be five times faster than the Pico W.
Example command format
pi@raspberrypi:~ $ iperf3 -c 192.168.1.68 -b 1M
5 GHz WiFi
Command
Bitrate
-b Transfer in Bandwidth
1 second
1M 128 KBytes 1.1 Mbits/sec
2M 256 KBytes 2.1 Mbits/sec
4M 512 KBytes 4.2 Mbits/sec
8M 1.0 MBytes 8.4 Mbits/sec
16M 1.9 MBytes 15.7 Mbits/sec
32M 3.8 MBytes 31.5 Mbits/sec
64M 7.6 MBytes 64.0 Mbits/sec
128M 9.9 MBytes 82.8 Mbits/sec
iPerf Pico W Server PC Client
At the time that this option was attempted, it did not lead to data transmission, but established connectivity.
Pico W Operation
>>> uiperf3.server()
Server listening on ('0.0.0.0', 5201)
Accepted connection: ('192.168.1.68', 49196)
Traceback (most recent call last):
File "", line 1, in /
File "/lib/uiperf3.py", line 302, in server
File "/lib/uiperf3.py", line 223, in server_once
File "/lib/uiperf3.py", line 59, in __init__
KeyError: pacing_timer
Windows PC Operation
D:\iperf>iperf3 -c '192.168.1.117'
Connecting to host 192.168.1.117, port 5201
[ 4] local 192.168.1.68 port 61546 connected to 192.168.1.117 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 256 KBytes 2.07 Mbits/sec
[ 4] 1.01-2.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 2.01-3.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 3.01-4.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 4.01-5.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 5.01-6.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.01-7.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 10.02-13.09 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-13.09 sec 256 KBytes 160 Kbits/sec sender
[ 4] 0.00-13.09 sec 0.00 Bytes 0.00 bits/sec receiver
iperf3: interrupt - the client has terminated
Pinging Remote Systems Next or Go To Start
Pinging Remote Systems
I suppose that the pinging could be described as network packet banging, as opposed to bit banging. One useful function is that, within WiFi access distance, a ping can detect that a Pico W is connected to the network and (hopefully) fully operational.
Pinging From PC to Pico W and Raspberry Pi - 2.4 GHz WiFi
In order to use the well known ping function, to obtain bottom line network performance information from the Pico W, it needs to be logged on as shown in “Connecting to the Internet with Raspberry Pi Pico W.pdf”. Initially, the function was not available from the Pico W but worked accessing the Pico from a remote computer.
For the first attempt, a Raspberry Pi 4B was pinged for comparison purposes, but pinging the Pico appeared to be unacceptably slow. I was advised that there was a CPU issue and need to initially execute a “wlan.config(pm = 0xa11140)” command via minicom (minicom -o -D /dev/ttyACM (needs to be logged on to network). Then, the more acceptable result, shown below, was produced. Individual speeds can vary but longer Pico and Raspberry Pi tests confirmed the same sort of average. But the first recorded time, as shown here, can be exceptionally long and should be ignored.
C:\Users\Roy>ping 192.168.1.117 PC to Pico W
Pinging 192.168.1.117 with 32 bytes of data:
Reply from 192.168.1.117: bytes=32 time=77ms TTL=255
Reply from 192.168.1.117: bytes=32 time=281ms TTL=255
Reply from 192.168.1.117: bytes=32 time=291ms TTL=255
Reply from 192.168.1.117: bytes=32 time=111ms TTL=255
C:\Users\Roy>ping 192.168.1.71 PC to P4
Pinging 192.168.1.71 with 32 bytes of data:
Reply from 192.168.1.71: bytes=32 time=289ms TTL=64
Reply from 192.168.1.71: bytes=32 time=2ms TTL=64
Reply from 192.168.1.71: bytes=32 time=2ms TTL=64
Reply from 192.168.1.71: bytes=32 time=2ms TTL=64
>>> wlan.config(pm = 0xa11140)
C:\Users\Roy>ping 192.168.1.117 PC to Pico W
Pinging 192.168.1.117 with 32 bytes of data:
Reply from 192.168.1.117: bytes=32 time=2ms TTL=255
Reply from 192.168.1.117: bytes=32 time=1ms TTL=255
Reply from 192.168.1.117: bytes=32 time=1ms TTL=255
Reply from 192.168.1.117: bytes=32 time=5ms TTL=255
The ping function has options to control the number of pings and data (buffer) size. Some versions have another option that determines frequency of pings, where the maximum seems to be 5 per second and default one per second. I tried recording sessions using PC Perfmon, but a few milliseconds activity per second from one ping produces results that are impossible to interpret.
Pinging Rasnberry Pi to Pico and PC Next or Go To Start
Pinging From Raspberry Pi to Pico W and PC - 2.4 GHz WiFi
Another issue, as reflected above, is that PC ping only records in, not really appropriate, whole milliseconds. A series of tests were carried out using Linux iPerf, with a Raspberry Pi pinging a PC and a Pico W, where timing is to two decimal places.
Following is an example of pinging a Pico W 30 times with 256 bytes of data, taking 30 seconds. Note the variation that might be influenced by other network activity, also the min/avg/max/mdev values at the end.
pi@raspberrypi:~ $ ping 192.168.1.117 -c 30 -s 256
PING 192.168.1.117 (192.168.1.117) 256(284) bytes of data.
264 bytes from 192.168.1.117: icmp_seq=1 ttl=255 time=7.13 ms
264 bytes from 192.168.1.117: icmp_seq=2 ttl=255 time=2.81 ms
264 bytes from 192.168.1.117: icmp_seq=3 ttl=255 time=4.26 ms
264 bytes from 192.168.1.117: icmp_seq=4 ttl=255 time=2.74 ms
264 bytes from 192.168.1.117: icmp_seq=5 ttl=255 time=2.88 ms
264 bytes from 192.168.1.117: icmp_seq=6 ttl=255 time=6.07 ms
264 bytes from 192.168.1.117: icmp_seq=7 ttl=255 time=94.5 ms
264 bytes from 192.168.1.117: icmp_seq=8 ttl=255 time=6.57 ms
264 bytes from 192.168.1.117: icmp_seq=9 ttl=255 time=31.0 ms
264 bytes from 192.168.1.117: icmp_seq=10 ttl=255 time=6.20 ms
264 bytes from 192.168.1.117: icmp_seq=11 ttl=255 time=3.19 ms
264 bytes from 192.168.1.117: icmp_seq=12 ttl=255 time=4.79 ms
264 bytes from 192.168.1.117: icmp_seq=13 ttl=255 time=2.73 ms
264 bytes from 192.168.1.117: icmp_seq=14 ttl=255 time=2.78 ms
264 bytes from 192.168.1.117: icmp_seq=15 ttl=255 time=2.81 ms
264 bytes from 192.168.1.117: icmp_seq=16 ttl=255 time=2.74 ms
264 bytes from 192.168.1.117: icmp_seq=17 ttl=255 time=4.51 ms
264 bytes from 192.168.1.117: icmp_seq=18 ttl=255 time=2.94 ms
264 bytes from 192.168.1.117: icmp_seq=19 ttl=255 time=2.73 ms
264 bytes from 192.168.1.117: icmp_seq=20 ttl=255 time=2.98 ms
264 bytes from 192.168.1.117: icmp_seq=21 ttl=255 time=2.75 ms
264 bytes from 192.168.1.117: icmp_seq=22 ttl=255 time=2.73 ms
264 bytes from 192.168.1.117: icmp_seq=23 ttl=255 time=5.43 ms
264 bytes from 192.168.1.117: icmp_seq=24 ttl=255 time=9.90 ms
264 bytes from 192.168.1.117: icmp_seq=25 ttl=255 time=3.22 ms
264 bytes from 192.168.1.117: icmp_seq=26 ttl=255 time=4.04 ms
264 bytes from 192.168.1.117: icmp_seq=27 ttl=255 time=7.15 ms
264 bytes from 192.168.1.117: icmp_seq=28 ttl=255 time=2.78 ms
264 bytes from 192.168.1.117: icmp_seq=29 ttl=255 time=2.75 ms
264 bytes from 192.168.1.117: icmp_seq=30 ttl=255 time=3.37 ms
--- 192.168.1.117 ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 76ms
rtt min/avg/max/mdev = 2.725/8.018/94.546/16.872 ms
Following are minimum, average and maximum recorded ping times, plus calculated averages for the fastest 80%, running the same tests from Raspberry Pi to Pico W and PC at one ping per second, with performance all restricted by 2.4 GHz WiFi links. Calculations on KBytes per second are included, representing data transfer speed when pinging, based on the 80% ratings. This takes into account that received data is returned to the sender, doubling the byte count.
At the lower byte counts, overheads lead to much higher PC data transfer speeds than on the Pico. At 4096 bytes, Pico performance approached that obtained sending data to the PC. The Pico did not accept 8192 byte transfers, but a test at 7000 bytes was successful, obtaining 1037 KB/second.
In both cases, maximum MB/second speeds approached the same order of magnitude as iPerf measurements, at 1.1 MB/second to the Pico and 5 MB/second to the PC. Here, the PC improvement involve its capability of accepting larger sized data transfers.
Pi 4 to PC I+O Pi 4 to Pico W I+O
80% KB/ 80% KB/
Bytes Min Max Avg Avg sec Min Max Avg Avg sec
32 2.0 117.3 9.8 2.5 26 2.5 153.0 14.9 3.9 16
64 2.1 83.0 10.1 2.6 49 2.4 303.2 17.8 4.0 32
128 2.1 92.7 7.7 3.1 83 2.5 122.8 12.6 2.9 88
256 2.0 123.3 16.5 2.9 177 2.7 94.5 8.0 3.3 155
512 2.4 74.6 11.3 3.3 310 3.0 84.0 9.8 4.2 244
1024 2.6 16.8 5.2 3.5 585 3.8 124.6 16.1 5.4 379
1536 3.2 256.5 15.7 4.1 749 5.0 81.3 14.6 7.5 410
2048 4.0 47.9 10.1 6.6 621 5.3 62.2 12.6 7.6 539
3072 3.8 57.6 8.6 4.8 1280 6.5 23.9 9.0 7.3 842
4096 4.0 100.5 17.5 6.9 1187 7.2 172.6 21.4 8.3 987
8182 7.4 44.1 12.0 9.3 1760
16384 8.8 30.1 14.1 10.9 3006
Pinging From Pico Next or Go To Start
Pinging From Pico
This was not included in the original software/firmware, but I was advised that uping.py was the one to use, available from github in a zip file -
download from here.
The unzipped file has to be copied into Thonny. Then, with Raspberry Pi Pico interpreter selected, Save As uping.py, via the Raspberry Pi Pico box, into the lib folder. In order to run the program, the usual log on and import steps are required. Following is the example from “Connecting to the Internet with Raspberry Pi Pico W.pdf”, pinging Google, with no extra parameters.
Import and Ping Google
pi@raspberrypi:~ $ minicom -o -D /dev/ttyACM0
>>> import network
>>> wlan = network.WLAN(network.STA_IF)
>>> wlan.active(True)
>>> wlan.connect('My Network Box', 'My Password')
>>> import uping
>>> uping.ping('google.com')
PING google.com (142.250.200.46): 64 data bytes
84 bytes from 142.250.200.46: icmp_seq=1, ttl=115, time=9.708000 ms
84 bytes from 142.250.200.46: icmp_seq=2, ttl=115, time=9.628000 ms
84 bytes from 142.250.200.46: icmp_seq=3, ttl=115, time=9.691000 ms
84 bytes from 142.250.200.46: icmp_seq=4, ttl=115, time=12.915000 ms
4 packets transmitted, 4 packets received
(4, 4)
Parameters are available to specify the number of pings, data size and interval. Following are the same measurements, quoted above, but running via uping from the Pico W. Intervals of 1000 were needed for approximate 1 per second pings.
At least, highest average speeds were similar from Pico to PC and Pi 4, but much slower than PC to Pico.
Ping PC
>>> uping.ping ('192.168.1.68', count=30, size=32, interval=1000)
To
>>> uping.ping ('192.168.1.68', count=30, size=4096, interval=1000)
In+Out 80% KB/Second
Pico Pico PC
Bytes min max avg 80% To PC To Pi4 To Pico
32 3.9 267.8 30.5 5.4 11.8 6.3 16.4
64 4.2 264.4 26.4 5.8 22.3 14.9 32.2
128 4.5 15.9 6.0 5.2 49.0 33.5 88.3
256 5.6 37.3 8.2 6.4 79.4 63.2 155.2
512 7.7 71.1 13.4 8.7 117.6 86.9 243.8
1024 12.2 35.1 15.4 12.7 161.9 135.0 379.3
1536 16.4 49.1 20.1 17.6 174.9 158.9 409.6
2048 20.2 27.2 21.8 21.0 194.6 145.8 538.9
3072 27.7 55.6 30.8 29.1 211.1 192.0 841.6
4096 36.1 86.1 40.7 37.4 218.8 187.2 987.0
Pinging To PC From Raspberry Pi With Performance Monitoring Next or Go To Start
Pinging To PC From Raspberry Pi With Performance Monitoring
The availability of short interval parameters can provide sufficient pings to provide meaningful results within Perfmon one second sampling. Perfmon headings are recorded Bytes (B) and Packets (P), Received R and Sent S, all per second.
For comparison purposes, the first results below are for Raspberry Pi pings to a PC. Each test executes 100 pings at minimum intervals of 200 ms, test durations being approximately 20 seconds. In this case, the total in plus out data transfer time only occupies a small part of the Perfmon one second sampling periods.
The results also show that multiple packets are transmitted, in this case, for data sizes greater than 1024 bytes, with the boundary between that and 1536 bytes.
pi@raspberrypi:~ $ ping 192.168.1.68 -c 100 -s 64 -i 0.2
To
pi@raspberrypi:~ $ time ping 192.168.1.68 -c 100 -s 4096 -i 0.2
Pi 4B Ping milliseconds I+O ---------------- PC Perfmon --------------
Size Min Max Avg 80% KB/s BR/sec BS/sec PR/sec PS/sec B/PR B/PS
64 1.8 103.0 5.9 2.8 46 570 547 5 5 104 104
256 1.9 112.0 12.0 2.4 213 1505 1503 5 5 290 289
512 2.1 36.3 3.2 2.3 445 2768 2757 5 5 526 533
1024 2.3 122.0 5.2 2.8 731 5349 5179 5 5 1034 1022
1536 2.9 123.0 13.5 4.3 714 8005 7996 10 10 781 788
2048 3.0 69.4 8.8 6.5 630 10634 10633 10 10 1044 1044
4096 3.7 55.8 8.3 6.3 1300 21552 21079 16 16 1315 1358
Pinging To PC From Pico With Performance Monitoring Next or Go To Start
Pinging To PC From Pico With Performance Monitoring
The next series of test results are from using uping from Pico to the PC with the minimum interval timing parameter. My first observation was that Perfmon mainly recorded that more data was transferred than that sent and returned.
It seems to me that the Pico W, or Python program, cannot handle these excessive demands, where some of the measurements are difficult to understand. Like at 4096 bytes, Perfmon is recording transferred data over 10 seconds, stop watch measured running time was 18.7 seconds and total measured ping times was 25.6 seconds.
>>> uping.ping ('192.168.1.68', count=500, size=64, interval=1)
To
>>> uping.ping ('192.168.1.68', count=500, size=4096, interval=1)
Pico W Ping milliseconds I+O =------------- PC Perfmon ---------------
Size Min Max Avg 80% KB/s BR/sec BS/sec PR/sec PS/sec B/PR B/PS
64 3.7 13.1 4.4 3.9 33 22509 22509 230 230 98 98
256 4.6 28.3 7.2 5.8 88 41147 41065 143 142 288 289
512 7.2 67.8 11.1 9.4 108 72760 72760 134 134 545 545
1024 11.3 21.1 15.6 14.7 139 90693 93686 86 92 1049 1018
1536 15.8 67.7 24.9 22.7 135 100005 99623 127 127 786 783
2048 19.6 125.0 32.6 28.8 142 100219 100379 128 129 784 780
4096 36.0 70.2 57.0 53.7 152 105615 105548 100 100 1058 1058
The latter tests were repeated using fewer pings, with various increased interval parameters, so that Perfmon recorded periods were greater than total pinging time. For example, with 4096 bytes Perfmon recordings spanned 14 seconds, test running time was 14.5 seconds, with 7.5 seconds pinging time, indicating around 7 seconds of pauses between pings.
Note how much this has reduced measured ping times. However, comparing the latter with those from Raspberry Pi to PC, indicates that the Pico W can be over five times slower, but with packet sizes being quite similar.
>>> uping.ping ('192.168.1.68', count=200, size=512, interval=10)
To
>>> uping.ping ('192.168.1.68', count=200, size=4096, interval=30)
Pico W Ping milliseconds I+O =------------- PC Perfmon ---------------
Size Min Max Avg 80% KB/s BR/sec BS/sec PR/sec PS/sec B/PR B/PS
512 6.5 30.8 8.0 7.0 146 31171 31254 57 58 546 538
1024 11.1 45.4 13.9 11.8 174 38148 38148 36 36 1058 1058
1536 15.5 98.6 18.8 16.1 191 43376 43376 54 54 802 802
2048 19.3 61.5 21.8 20.2 203 44505 44505 42 42 1058 1058
4096 35.3 63.5 37.5 36.0 228 62100 62100 44 44 1399 1399
Pico to Raspberry Pi With Linux Performance Monitor Next or Go To Start
Pico to Raspberry Pi With Linux Performance Monitor
In order to see whether Perfmon or the PC affected the strange overloaded performance, the 4096 byte test was repeated with Pico W pinging a Raspberry Pi 4B, monitored by the Linux SAR command, available after installing sysstat. This produces a lot of output, with final averages, So I ran 5 second samples during pinging for quick answers.
The tests were run using 200 pings with intervals of 1 and 30. With the latter, all main performance measures were essentially the same as Pico to PC, with 200 pings. Then, with the minimum interval, they were in the same overloaded ballpark as Pico to PC with 500 pings.
>>> uping.ping ('192.168.1.71', count=200, size=4096, interval=1)
and
>>> uping.ping ('192.168.1.71', count=200, size=4096, interval=30)
SAR -n DEV 1 5
Size 4096 rxkB/s txkB/s
Pico W Ping milliseconds x 1000 x 1000 rxpck/s txpck/s
Interv Min Max Avg 80% KB/s BR/sec BS/sec PR/sec PS/sec B/PR B/PS
1 40.9 103.0 69.3 68.6 119 112180 116760 83 84 1352 1390
30 36.6 163.8 45.5 41.2 199 57470 58910 46 45 1249 1309
Checking For Errors
Other SAR and Perfmon tests, that check for errors, were carried out, without identifying any. Performance monitoring was also included to help those who are unaware of these functions see a way to measure network performance, particularly for Pico W,
Pinging Pico W Whilst Bit Banging
On pinging to a PC or a Raspberry Pi, performance monitoring indicates that the data flow can be seen inside the remote computer. I tried a few pings to the Pico whilst is was bit banging, to confirm that it was possible with no apparent side effects.
Wiring Details Next or Go To Start
Wiring Details
The test bed setup, comprises 11 LEDs, connected to ground with input for each supplied via 220 ohm resistors. Then there is one output connected directly to ground via a 330 ohm resistor, plus another output connected to a Pi 4 input pin, via 1000 ohms, that is for monitoring transmitted signal frequencies (see Pi 4 monitoring program information below).
The simple diagrams below show which of the pi 4/400 and Pico physical pins are used. As shown in the benchmark listings, I included these physical pin numbers in the program pin names to help in understanding the different program structures. The names are allocated to the partner logical pin numbers in the programs, in this case the standard ones for Pico and those required by WiringPi for the Pi computers.
The top three Pico connections to the Pi 4 are for serial I/O to allow program printed output to be displayed in a Pi 4 or Pi 400 Terminal window, following executing the appropriate minicom command.
Pi 4 or Pi 400 Pico Top
_________________
| USB
1 2| Pi 4 10< 1 40
3 4| Pi 4 8< 2 39
5 6| >GROUND PI 4 14< 3 38
7 8| < Pico 2 4 37
9 10| < Pico 1 5 36
11 12| LED< 6 35
Pi 4/400 INPUT> 13 14| < Pico 3 LED< 7 34
LED< 15 16| >LED 8 33
17 18| >LED LED< 9 32
19 20| LED< 10 31
21 22| >INPUT LED< 11 30
23 24| LED< 12 29
25 26| 13 28
27 28| LED< 14 27
1kR< 29 30| LED< 15 26
LED< 31 32| >LED LED< 16 25
LED< 33 34| 1kR< 17 24
LED< 35 36| >LED 18 23 >GROUND
LED< 37 38| >LED LED< 19 22
39 40| >LED LED< 20 21 >Pi 4/400 INPUT
|
| < Pi 400 bottom
Raspberry Pi Input Cycle Counter
An experimental C program was written to monitor incoming cycles per second, compiled as incount for use on a Raspberry Pi 4. The program listing and examples of use are included in
Raspberry Pi Pico, Pi 4 and Pi 400 Python and C Basic Beginners Bit Banging Benchmarks.pdf, in case anyone is interested in playing with it.
Test Rig Photograph
Go To Start
|
|